REMARKS 

Reconsideration and allowance of this application are respectfully requested in light of 
the above amendments and the following remarks. 

The specification has been amended to overcome the applied objection. No new matter is 
believed to be introduced by the amendment. 

Claims 83, 84, 87, and 100 have been amended to overcome the objections applied 

thereto. 

Claims 79-82, 86, 88-97, 100-103, 106-1 1 1, and 1 18 stand rejected, under 35 USC 
§ 103(a), as being unpatentable over Nokia's 3GPP contribution "QoS and Scheduling Principles 
in USUPA," (R2-041519) in view of Kekki (US 2005/0073953) and Schultz (WO 01/63855). 
Claims 83, 84, 99, and 1 13 stand rejected, under 35 USC § 103(a), as being unpatentable over 
Nokia in view of Kekki, Schultz, Lucent's 3GPP contribution "Scheduled and Autonomous Mode 
Operation for the Enhanced Uplink/' (Rl-030284). Claims 85, 87, 104, and 105 stand rejected, 
under 35 USC § 103(a), as being unpatentable over Nokia in view of Kekki, Schultz, and Fujitsu's 
3GPP contribution "Signaling Framework for Enhanced Uplink Scheduling," (R 1-040999, R2- 
041622). Claims 98 and 112 stand rejected, under 35 USC § 103(a), as being unpatentable over 
Nokia in view of Kekki, Schultz, and Cheng et al. (US 2004/02283 1 3). Claims 11 4-1 1 7 and 1 1 9 
stand rejected, under 35 USC § 103(a), as being unpatentable over Nokia in view of Cheng. The 
Applicants respectfully traverse these rejections on the grounds set forth below. 

Claim 79 defines a transmission scheduling method in which a base station: (1) receives 
from a radio network controller (RNC) quality of service (QoS) attributes of multiple data flows 
to be multiplexed onto a dedicated uplink channel by a mobile terminal and (2) schedules 

14 



resources on the uplink channel based on the received QoS attributes related to a data flow 
identified in a scheduling request received from a mobile terminal. The claimed subject matter 
provides an advantage in that it supports scheduling data flows within an uplink channel based 
on (1) a scheduling request, from a mobile terminal, for the data flow and (2) QoS attributes, 
received from an RNC, of the data flow, so as to enhance the prioritization of the scheduling of 
data flows. 

The Office Action proposes that Terry discloses the Applicants' claimed subject matter of 
a base station that receives, from a mobile terminal, a scheduling request comprising an identifier 
that identifies one of a plurality of data flows to be multiplexed into a single dedicated uplink 
channel and schedules uplink channel resources based on QoS attributes related to the data flow 
identified by the identifier (see Office Action, paragraph bridging pages 1 1 and 12). 

The Applicants respectfully disagree. 

By contrast to the instant claimed subject matter of a base station that receives a 
scheduling request comprising an identifier that identifies one of a plurality of data flows, Terry 
discloses a base station that receives a rate request providing a quality of service (QoS) indication 
(e.g., a desired data rate). Terry's rate request does not identify the data flow or data flows to 
which it relates. The base station thus never knows the data flow(s) to which a rate request 
relates, only the requesting user equipment knows this. More specifically, Terry discloses that an 
enhanced uplink (EU) rate request communicated from a wireless transmit/receive unit (WTRU) 
to a base station includes an indication of a quality of service (QoS) that is appropriate for each 
M AC-d data flow to be multiplexed by the WTRU into a MAC-e protocol data unit (PDU) 
communicated on an enhanced dedicated uplink channel (E-DCH) (see Terry paragraph [0016], 
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lines 1-3, paragraph [0019], lines 4-7, and paragraph [0023, lines 1-4]). The EU rate request may 
be a traffic volume indicator, a requested data rate, a transport format combination (TFC) index, 
or a traffic volume measurement (TVM) for each data flow (see paragraph [0019], lines 4-7). 
Each of: (1) a traffic volume indicator, (2) a requested data rate, (3) a TFC index, and (4) a TVM 
is an indication of QoS, not an identifier of a MAC-d data flow to be multiplexed into a MAC-e 
PDU. 

Based on all of the EU rate requests received from a WTRU, Terry's base station 
generates and sends a rate grant to the WTRU that identifies a TFC set (TFCS) from which the 
WTRU may select one TFC for multiplexing the MAC-d data flows onto the E-DCH (see Terry 
paragraph [0028], lines 1-8, and paragraph [0023], lines 1-4). Thus, only Terry's WTRU knows 
the identity of the MAC-d data flows to be multiplexed onto the E-DCH. From the foregoing, 
because Terry's bases station never receives an identification of a particular data flow from the 
WTRU, it necessarily follows that Terry also cannot disclose the instant claimed subject matter 
of a base station that schedules resources on an uplink channel based on QoS attributes, received 
from an RNC, related to a data flow particularly identified in a scheduling request received from 
a mobile terminal. Moreover, Terry's base station cannot schedule resources on the UL channel 
of multiple data flows to be multiplexed onto the UL channel without knowing the QoS attributes 
of the individual data flows. 

In brief, Terry's base station never receives an identifier of the individual data flows from 
the WTRU. Instead, Terry's base station schedules resources on the E-DCH based on each data 
flow's QoS requirements. Only Terry's WTRU (1 ) knows which particular MAC-d data flow is 
associated with a particular rate request and its associated QoS requirement and (2) assigns a 
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TFC from the set of TFCs received from the base station to each MAC-d data flow to be 
multiplexed onto the E-DCH. 

The Office Action appears to recognize that Terry does not disclose the Applicants' 
claimed subject matter of communicating an identifier of a data flow in a scheduling request to a 
base station. More specifically, the Office Action proposes that Terry discloses communicating 
an "EU rate request ... for each data flow" (see Office Action page 1 2, lines 4-5). However, 
communicating an EU rate request for each data flow is not the same as communicating an 
identifier of each data flow. Without the knowledge of the identifier of each data flow, the base 
station cannot schedule resources on the UL channel with respect to the multiple data flows to be 
multiplexed onto the UL channel, based on QoS attributes of the individual data flows; thus, 
Terry cannot achieve the subject matter of the present claimed invention. 

The Office Action also proposes that Nokia discloses a data flow identifier and that each 
data flow has a QoS stored in a Node-B (i.e., base station) (see Office Action page 12, lines 3-4). 
However, Nokia discloses that: (1) each MAC-d data flow has associated priority queues, (2) 
user equipments (UEs) make rate grant requests per priority queue, (3) the Node-B knows the 
relative priority of each queue, and (4) the Node-B scheduler schedules communication resources 
based on the received rate grant requests (see Nokia, Fourth Option section). 

However, the Applicants submit that Nokia does not disclose that each MAC-d data flow 
has a QoS stored in the N6de-B, contrary to the position taken in the Office Action. Instead, 
Nokia discloses that the Node-B knows the relative priority of each priority queue (see Nokia, 
Fourth Option section, line 2). Moreover, Nokia expressly discloses that each MAC-d data flow 
has multiple queues (see Fourth Option section, lines 1 and 6). Nokia does not disclose that the 
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Node-B knows which priority queues correspond to a particular MAC-d data flow. At most, 
what may be inferred from Nokia's disclosure is that Nokia's UE knows the identity of each 
MAC-d data flow and its associated priority queues. 

Thus, Nokia does not supplement the teachings of Terry with regard to the above- 
mentioned subject matter distinguishing claim 79 from Terry's disclosure. Kekki and Schultz are 
not cited in the Office Action for supplementing the teachings of Terry and Nokia in this regard. 

Accordingly, the Applicants submit that the teachings of Nokia, Kekki, Schultz and 
Terry, considered individually or in combination, do not render obvious the subject matter 
defined by claim 79. Independent claims 100, 114, 116, and 1 18 similarly recite the above- 
mentioned subject matter distinguishing method claim 79 from the applied references, but claims 
1 00, 11 6, and 1 1 8 do so with respect to an apparatus. With regard to claims 1 1 4 and 1 1 6, Cheng 
is not cited in the Office Action for supplementing the teachings of Nokia with respect to the 
above-mentioned distinguishing subject matter. Therefore, the rejections applied to claims 83- 
85, 87, 98, 99, 104, 105, 1 12, and 1 13 are considered to be obviated and allowance of claims 79, 
100, 1 14, and 166 and all claims dependent therefrom is therefore warranted. 

To promote a better understanding of the patentable distinctions of the instant claimed 
subject matter over the individual or combined teachings of the applied references, the 
Applicants provide the following additional remarks. 

The Office Action proposes that Nokia "clearly discloses in the first paragraph [of option 
4, Section 2.1] that there is MAC-d and MAC-e multiplexing and de-multiplexing" (see Office 
Action page 2, first 2 paragraphs). 

The Nokia reference recites: 
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The fourth option, each MAC-d flow would have priority queues for different priorities in 
MAC-e of the UE and the Node B knows the' relative priority of each queue. The Node B 
scheduler could take this relative priority of different f/MAC-d flows]] priority queues 
into account when performing the scheduling decision based on different rate grant 
requests from different UEs, ifUEs are making grant request per priority queue. 

Essentially, as outlined in section 6.4.2 of the previously filed Declaration under 37 CFR 
1.132 and as illustrated in Fig. 5 of this application, this means that each MAC-d flow is 
provided with multiple priority queues, one priority queue for each logical channel priority (see 
Fig. 4 of the instant application, "RLC and higher layer entities" provide data in the form of 
logical channels to the MAC-d entity). Accordingly, when grant requests from the UEs are sent 
per priority queue, the Node B scheduler can take the relative priority of different priority queues 
into account in the scheduling decision. (It should be noted that references herein to the 
specification and drawings are for illustrative purposes only and are not intended to limit the 
scope of the invention to the referenced embodiments.) 

Furthermore, it is clear to the skilled reader that in case a grant request is sent per priority 
queue, then there will also be a rate grant per priority queue and thus only data of one priority 
queue is transmitted within a transport block (the data unit formed for transmission on the E- 
DCH by MAC-e) in a given transmission time interval. 

The Nokia reference continues: 

Thus this solution would not set any restrictions on possible MAC-d multiplexing options. 
However the full flexibility, introduces some extra complexity as priority queue 
distribution and multiple priority queues per MAC-d flow would be needed in UEs, and 
on the network side the reordering would be needed to be done separately for each 
priority, i.e. each priority would need separate reordering buffers, compared to solution 
3 where only one priority queue and reordering buffer is needed per MAC-d flow in UE 
andinSRNC. 
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Multiplexing in the context of the present claimed invention means that the data from 
different flows is assembled and transmitted together in a single transmission. However, even if 
a system were to use multiple priority queues to which the individual MAC-d flows can be 
distributed, this would not mean that there is any multiplexing of these MAC-d flows, 
respectively, from the priority queues provided. It is clear from the above and as also confirmed 
by Mr. Lohr in the Declaration, section 6.4.2, page 7, the expression "MAC-d multiplexing" is 
related to the multiplexing of logical channels to a MAC-d flow, but not the multiplexing of 
MAC-d flows to different priority queues in MAC-e. As outlined above, each MAC-d flow is 
distributed (de-multiplexed but not multiplexed as stated in the Applicants' claimed subject 
matter) to different individual priority queues, according to logical channel priorities of the 
logical channels (that have been multiplexed to the MAC-d flow) — i.e. data of logical channels 
with the same logical channel priority on the MAC-d flow get mapped to the same priority 
queue. 

As to the mentioning of reordering, this is related to the Node B receiving the transport 
blocks transmitted by the UE via the E-DCH (see Fig, 6 and Fig. 7 of the instant application). As 
data of a single priority queue is transmitted in a respective transport block and each transport 
block is transmitted using a HARQ process, it might happen that some transport block is still 
pending for retransmission in a HARQ process, while another HARQ process successfully 
received and decoded another transport block that first transmitted later than the transport block 
in retransmission. To reconstruct the correct sequence of the transport blocks, reordering queues 
are used in the Node B. If this reordering is performed on the priority queue level, the 
complexity is increased as recited in the passage above. 
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The next passage in the Nokia reference suggests a simplification: 

If the re-ordering is done on logical channel level, separate re-ordering distribution is 
not needed, as there would be one re-ordering queue per logical channel after MAC-e 
and MAC-d de-multiplexing. 

Hence, the reordering can be simplified if the data units provided by the MAC-d entity to 
the higher layers (i.e. the logical channel data units — MAC-d PDUs) are reordered. 

Overall, however, the terms "multiplexing" and ,, de-multiplexing , ' appear in the recited 
passage of section 2.1 of the Nokia reference in connection with the data processing in the MAC- 
d and MAC-e; this does not mean that the passage is teaching the multiplexing of MAC-d flows 
or priority queues to v a single dedicated uplink channel ("flows to be multiplexed onto a single 
dedicated uplink channel" — claim 79). 

If considering the teaching of the Nokia reference that logical channels are multiplexed to 
a MAC-d flow ("MAC-d multiplexing"), then the flows mentioned in the claim language would 
correspond to logical channels, which would however require that this mapping of the term 
"flow" in the claim language to "logical channel" in the Nokia reference needs to be maintained 
when considering the further features of the claims. In this case the scheduling request as per 
claim 79, would not be identifying any logical channel, but is merely transmitted for a priority 
queue. 

As to the mentioning of the "NEC document" in item 3 a), page 2, 2nd paragraph of the 
Office Action, if the term "MAC-d flow multiplexing" and QoS being associated with a MAC-d 
flow is mentioned there, still this does not suggest or motivate one skilled in the art to 
incorporate this feature in the proposal of Nokia. If the MAC-d flows would be multiplexed to a 
single priority queue, the idea of distributing the MAC-d flow to different priority queues 
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according to the logical channel priority of the logical channel data on the MAC-d flow would be 
contradicted , as the scheduling could no longer differentiate the relative priority of the priority 
queues in its scheduling. 

In regard to item 3 b) and item 7 of the Office Action: 

a) As to the presence of QoS attributes, the Office Action proposes that the relative 
priority of the queues of the MAC-d flows within Nokia would correspond to the claimed QoS 
attribute. In contrast to the Office Action's point of view, the Applicants' claimed invention not 
only requires a channel QoS attribute, but, after amendment, relates to QoS attributes, i.e., plural 
QoS attributes. 

b) Furthermore, the Applicants have not admitted that the priority of the flow is known to 
the Node B. The Declaration stated that the relative priority is known to the Node B — as 
emphasized in the Declaration, section 6.2.4, the Node B knows only the relative priority of the 
individual MAC-d flows served by the Node B. 

c) In addition, the subject matter of instant claim 79 makes clear that the QoS attributes 
considered in the scheduling are those provided for the respective flows from the RNC. 
Accordingly, claim 79 clearly links the QoS attributes received from the RNC at the Node B to 
those QoS attributes actually used for scheduling. No such teaching is provided in the applied 
references. 

In regard to item 3 c) and item 8 of the Office Action: 

a) The Office Action notes that Nokia teaches the presence of a service priority indicator 
which is used in formulating any signaling, so that it would be obvious that a flow indicator can 
be used for the UE scheduling request (see also item 16 of the Office Action). Item 6.2.4 in the 
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Declaration relates to the factual teaching of the Nokia reference and not to what could be 
obvious from this teaching. Furthermore, it is apparent from the name "service priority 
indicator" that this indicator relates to indicating the service priority and has nothing to do with 
indicating a respective flow. Accordingly, from these reference teachings, it appears not even 
obvious to include a flow identifier instead of a service priority identifier to the scheduling 
requests as recited by the independent claims. The Office Action's argument on this point seems 
heavily based on an ex-post facto analysis of the invention. 

In regard to item 3 d) and item 9 of the Office Action: 

The Office Action proposes that Kekki was only introduced to disclose receiving at the 
base station from a Radio Network Controller QoS information. Kekki's QoS information 
provided from the RNC to the Node B has nothing to do with the actual QoS attributes used for 
scheduling the transmissions of the UE on the air interface. In the invention of instant claim 79, 
the QoS attributes received from the RNC are used for scheduling the UE according to its 
scheduling request. 

Therefore, Kekki's teaching that arbitrary QoS information is provided to the Node B 
from the RNC, does not render the differences between the Nokia reference and the claimed 
invention obvious. 

In regard to item 3 e) and item 9 of the Office Action: 

a) The Office Action proposes that Schultz suggests a scheduling function may be applied 
within a UMTS MAC layer "in an RNC, UE, etc." (see Office Action page 21, lines 30-31). The 
Office Action proposes that this suggests that the scheduling function is actually performed by 
the Node B, as this statement in Schultz does not preclude the Node B* s MAC layer. 
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b) However, the recited passage clearly states that it is the UMTS MAC layer in an RNC 
or a UE that is provided the scheduling function. Accordingly, it is not any arbitrary UMTS 
layer. 

Furthermore, the Node B's MAC layer is not mentioned in Schultz and in view of the 
underlying system configuration assumed by Schultz is also not likely to be a network node in 
which the scheduling function should reside. Essentially, the Office Action appears to read the 
Node B into the "etc." of this short list of the MAC layer termination points listed by Schultz. 
However, it appears inadequate and based on hindsight from the claimed invention to conclude 
from this statement in Schultz that the Node B is to perform a scheduling function. 

In view of the above, it is submitted that this application is in condition for allowance and 
a notice to that effect is respectfully solicited, 

Respectfully submitted, 

/James Edward Ledbetter/ 
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